-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade vendored packaging lib #12300
Conversation
d9546f5
to
63897d3
Compare
@pypa/pip-committers this is a quick try at upgrading The tests that need fixing may reveal a few interesting things. In particular I wonder if we should worry about 920c4fc. When the |
And the last failing test ( |
af9fbb4
to
fd89669
Compare
828a7d3
to
3af04b6
Compare
f731c58
to
62e9e9b
Compare
I just tried a couple of quick changes to the |
Quoting @pfmoore from the discussion above...
Ugh, this is a nuance that I missed digging into this head-first. Indeed, |
Nice! Looks like you may have fixed it @pradyunsg 🙂 I hadn't thought to go the whole way and manage getting the extras from the metadata directly (effectively copying the |
0b6ebfa
to
7db6cb3
Compare
Ohkie, this last commit is an attempt at simplification -- we might want to leave it out if it isn't all-green, since it's unlikely I'd get a chance to look at this again before Monday morning. |
I've taken the liberty to mark this as ready for review. |
As I do that though... I'm realising that one thing that we ought to validate is whether there are suboptiomal behaviours/failure modes, when given a legacy version or specifier; coming via the index page, a built wheel, a project's metadata and various other data sources that pip interacts with. |
This is not ready indeed. There is work to do to ignore invalid versions in indexes (e.g. |
Other fails include FYI in PR #12327 I am currently filtering out invalid file name and version name packages as Pip collects them in that particular scenario, not sure if that's the going to be the prefered way to do it. |
Yeah, I now remember why I said I would not have time to do this before the release. I somehow had managed to forget about #12300 (comment) when I created this PR. This seems to be way too far reaching to do so late in the release cycle. So I think I'll postpone it. |
Are there issues tracking these (that we could put into the 24.0 milestone)? If we don't have some means of tracking what's needed to get this landed, I fear we're going to be in the same situation next release - in spite of no-one liking it, vendoring upgrades tend to get ignored until late in the release cycle... |
We do this by adding a version_str property to BaseDistribution, which allows us to access the version without parsing it.
We do this to avoid needlessly building a sdist when we have determined that a wheel has invalid metadata.
Dependencies should be more precise than requirements;
The pkg_ressources metadata backend does not suffer from invalid metadata in this test case.
dc2b212
to
84ad55a
Compare
This breaks pip on the CPython maintenance branches as the version reported by Python ends with a
Bisected to 47a8480 specifically. |
Upgrade our vendored copy of
packaging
, remove all references toLegacyVersion
andLegacySpecifier
.Closes #12063
Closes #11715
Closes #11445
Closes #7650
Closes #9613
Closes #10098
TODO